[笔记系列文章说明]: 该类型的文章是笔者学习过程中整理的学习笔记.
帮助理解
技术债务:没有按照规范所编写设计的代码(走捷径),或者错误代码.
这些产生的问题,需要在以后的工作中需要被修复所花的时间(即称为债务).
本地Sonarqube环境
测试地址:192.168.10.221:9000 用户名:admin 密码:admin 数据库:192.168.10.222 scholar2test/scholar2test
#####根据债务的不同特性分为8种:
下图对应:
可重用性
可移植性
可维护性
安全性
实用性
效率
可变性(低耦合?)
可靠性
可测性
产生以上技术债务的原因有大概七种（常用原因，默认规则）:
1:Bug和潜在的Bug
2,违反编码标准
3,重复
4,单元测试信息
5,复杂的代码
6,结构设计
7,注释
重新强调使用sonar为了什么
产生债务原因已经找到，通过人力去分析代码，进行优化改进比较麻烦。通过工具，按照我们使用者的意愿去分析代码并且呈现出来，这些就是sonar所要做的事情。
前提：想要对项目进行严格的分析，修改，把控，需要项目具有良好的编码规范。没有这方面需求，使用sonar没有意义。
以下介绍七种产生债务原因在图形化界面上的查看与分析方式
以下会穿插部分界面的解释，以默认规则，默认插件为例。
1:Bug和潜在的Bug
根据字面意思可以理解
这种原因通常问题严重性标记为:Blocker(阻断)
通过下图观察：
点击问题进入如下图:
名词解释:
规则组：若干规则组成的策略.
扩展
1,这些问题生成的依据 叫做规则
2,规则存在于规则组中
3,如何查看和配置规则组?
通过新建规则或者修改规则,确定规则下的问题等级.比如点击findbugs规则组,显示如下
列出5个级别问题的对应规则数量.点击后查看对应的规则,并且能够通过操作对规则产生的问题级别进行修改,或者从本规则配置中去掉规则.
另外一种直接进入rules菜单下进行对规则的操作
具体规则操作见下文.
2,违反编码标准
命名习惯,代码格式,常量大写等.
3,重复
解释:
重复的意思是重复相似的代码
监测显示重复的面板如下图:
点击进入重复详细内容,见下图.大多数视图都可以纵深到具体代码.
如何查看重复代码,点击如下图的橘黄色线,弹出重复位置提示
默认重复检查只检查一个项目内的,,要实现多个项目之间的重复检查需要设置,如下图:
4,单元测试信息
解释:
单元测试覆盖率.
面板如下图:
结合分析时采用插件
详细使用参考:http://docs.sonarqube.org/display/SONAR/Lack+of+Unit+Tests
由于项目中没有用到,暂时没有分析.
5,复杂的代码
解释:
一个文件或者方法,放入了太多逻辑,相应的复杂度就会增加.
权值:复杂度/方法
柱状图从左到右权值上升 柱状图的高度为文件或方法数.
方法:平均权值
类:类的平均复杂度
文件:包的平均复杂度
6,结构设计
主要体现在三个方面:
(1)同级相互调用关系,死锁等
(2)层次结构调用关系,编码分层调用,如mvc,mvp等
(3)包的管理
(1)同级相互调用关系,死锁等
选中文件:
蓝色表示选中的文件或包,绿色表示依赖于选中的蓝色文件或包
黄色表示蓝色依赖的文件或包
双击组件进入子组件依赖关系图
选中右边格子
绿色依赖黄色,数字代表依赖个数,红色代表存在反向依赖,数字代表反向依赖的个数.出现红色表示容易造成循环的地方.
出现这种相互调用的,就要考虑设计是否合理
双击单元格显示依赖文件详情:
(2)层次结构调用关系,编码分层调用,如mvc等
以下介绍如何设置可以自定义规则来使自定义约束起作用.
增加架构约束规则,来分析显示层级调用关系
例:
Rules中查找Architectural 规则 (此规则主要用于架构规则定义)
点击create按钮,自定义规则
设置规则参数
分配规则(把规则加入到规则组,规则组应用于具体项目)
(3)包的管理
引用包的管理,点击Libraries栏目显示项目引用包
另外可以根据依赖关系查看包的使用情况,具体操作
点击右上角的usages按钮,进入包的使用查询,如下图
7,注释
下图显示注释分析情况:
点击进入,以权值排列显示
具体的注释量取决于具体的项目设计情况.
终
Sonar不能直接提高我们的代码质量和优化项目结构，只是用来反应我们的问题，间接关系。